home *** CD-ROM | disk | FTP | other *** search
/ Just Call Me Internet / Just Call Me Internet.iso / others / crypt / pgp262st / doc / changes.doc < prev    next >
Text File  |  1994-10-15  |  21KB  |  441 lines

  1. [Note: This file now contains all the information that used to be in
  2. the newfor22.doc through newfor26.doc, starting with the most recent
  3. information first]
  4.  
  5. Changes for PGP 2.6.2
  6.  
  7. - Some people reported a "bug" that you could stick an extra paragraph
  8.   in the beginning of a clear-signed message and PGP would still report
  9.   a good signature.  PGP allows comment "headers" before ASCII-armor
  10.   blocks (like the Version: header that's there for debugging
  11.   purposes), terminated, as with e-mail and usenet messages, by a blank
  12.   line.  These headers are just window dressing; PGP ignores them.  So
  13.   this is actually a "feature"; the bug is that people think it's part
  14.   of the signed message.  There are a number of ways to fake the
  15.   visual appearance of a blank line using common file-viewing
  16.   utilities, a blank line is easy to miss even if you know about it,
  17.   and headers are not presently used in clear-signed messages.  So now
  18.   headers are forbidden at the beginning of a clear-signed message.
  19.   Also, PGP enforces an RFC-822-like syntax on header lines before ASCII
  20.   armor.
  21.   Note that in no case has PGP's output ever been compromised; the problem
  22.   arises only if people see the "good signature" message but try to read
  23.   the input directly to see what was signed.
  24. - Closed files properly in a number of error situations, which also helps
  25.   PGP run under OS/2. (Contributed by John Frickson)
  26. - Improved OS/2 makefile target.
  27. - Added a few contributed makefile entries (hpux9, amix, encore, machten)
  28. - Fixed MAX_BIT_PRECISION to 2048.
  29. - Changed the +'s printed during prime generation (to indicate that a
  30.   candidate prime just passed a Fermat test) to *'s, since some people's
  31.   modems go into command mode when fed slow strings of +'s.
  32. - Added a copyright notice for RSAREF.
  33. - Updated the manual-checking error message to tell people that they
  34.   can find a simple fix if they RTFM.  Hopefully this will further
  35.   encourage people to complain to whoever distributed PGP without the
  36.   manual instead of just getting frustrated.
  37. - Fixed (at long last) PGP's table of file extensions to know that
  38.   gzip is .gz, and not .z. (Which was the preferred form some time ago.)
  39. - Fixed a bug in key editing with the public and secret keyrings in
  40.   different directories.  The old code was assuming they were in the same
  41.   directory, which used to be a safe assumption, but no more.
  42. - Fixed a problem with access() on VMS returning failure when fed a
  43.   directory that exists.
  44. - Enlarged randseed.bin to hold more entropy, and arranged for it to be
  45.   saved on each invocation of PGP so the entropy from keystrokes while
  46.   not encrypting would be available for future use.  See the comment in
  47.   random.c for implementation details.
  48. - A problem checking separate signatures on files with upper-128
  49.   characters has been fixed.  PGP was assuming that since MS-DOS uses
  50.   CRLF line endings, files for signature testing are already in canonical
  51.   test format.  This is not true if upper-128 characters are in use.
  52. - Got rid of pkcs_compat as redundant.
  53.  
  54. Changes to PGP 2.6.1
  55.  
  56. PGP 2.6.1 is a bugfix release of PGP 2.6. It fixes many bugs that have been
  57. reported by the PGP user community since the original release of PGP 2.6
  58. back in May of 1994. The most notable bugs are the "xorbytes" bug that
  59. resulted in less randomness then full Shannon Entropy for all key bits.
  60. (Note: People who generated keys with PGP 2.6 do *not* need to generate
  61. new keys). Another bug that manifested itself as "DOS error 8" errors has
  62. also been fixed. It is also safe to edit your key userid with PGP 2.6.1
  63. even if you store your passphrase in the PGPPASS variable.
  64.  
  65. PGP 2.6.1 will now accept keys up to length 2,048 bits, however it
  66. will still only generate keys up to 1,024 bits. This is a phased
  67. upgrade approach to increasing PGP's keysize.
  68.  
  69. Changes to PGP 2.6:
  70.  
  71. This version of PGP uses a version of RSAREF provided to MIT by RSA Data
  72. Security for use in PGP. This version is legal within the U.S.  See the
  73. enclosed RSAREF license for full details. Basically this is a
  74. non-commercial release. If you want to use it in a commercial or
  75. governmental setting, talk to ViaCrypt (2014 West Peoria Avenue,
  76. Phoenix, Arizona 85029, +1 602 944-0773).
  77.  
  78. While PGP version 2.5 used RSAREF version 2.0, PGP 2.6 uses RSAREF
  79. version 1.  This change was made in consultation with RSA Data
  80. Security, which is currently revising its version 2.0 distribution.
  81. The version of RSAREF included with this distribution is RSAREF
  82. version 1, not version 2.0.
  83.  
  84. PGP 2.6 will read messages, signatures and keys created with versions of
  85. PGP post 2.2. (i.e., 2.3, 2.3a, 2.4 and 2.5). However after 9/1/94 Version
  86. 2.6 will create messages which contain a version number of "3" in signatues,
  87. messages and keys (see pgformat.doc for details). PGP2.6 will be able to
  88. read these signatures, messages and keys, but prior versions will not.
  89.  
  90. Versions prior to 2.6 would not permit a new signature to be added to a key
  91. if there was an already existing signature from the same signer. Starting
  92. with version 2.6 newer signatures will override older ones *as long as the
  93. newer signature verifies*. This change is important because many keys have
  94. signatures on them that were created by PGP version 2.2 or earlier. These
  95. signatures can not be verified by PGP 2.5 or higher. Owners of keys with
  96. these obsolete signatures should attempt to gather new signatures and
  97. add them to their key.
  98.  
  99. Significant changes were also made for version 2.5. Because version 2.6 is
  100. coming out very soon after 2.5 (which was only really a beta test version)
  101. readers are encouraged to read the file "newfor25.doc" as well as this file.
  102.  
  103. Changes to PGP 2.5:
  104.  
  105.                  ***** MOST IMPORTANT *****
  106.  
  107. This version of PGP uses RSAREF 2.0, so it's legal in the U.S.!  The
  108. RSAREF license forbids you to (among other things; see the license for
  109. full details) "use the program to provide services to others for which
  110. you are compensated in any manner", but that still covers a lot of
  111. people.  If you want to use it in a commercial or governmental
  112. setting, talk to ViaCrypt (2014 West Peoria Avenue, Phoenix, Arizona
  113. 85029, +1 602 944-0773).
  114.  
  115. PGP 2.5 should always be distributed with a copy of the RSAREF 2.0
  116. license of March 16, 1994 from RSA Data Security, Inc., so that all
  117. users will be aware of their obligations under the RSAREF license.
  118.  
  119. Since the RSAREF license conflicts with the GNU General Public License that
  120. PGP was formerly distributed under, the GPL had to go.  PGP is still
  121. freely distributable, though.  (From a copyright point of view; export
  122. controls or some other legal hassle may apply.)
  123.  
  124. *** IMPORTANT CHANGE:
  125.  
  126. RSAREF 2.0 can understand only the pkcs_compat=1 formats for signatures
  127. and encrypted files.  This has been the default since 2.3, so old files
  128. should not be too much of a problem, but old key signatures will
  129. encounter difficulties.  This change will result in a hole being ripped
  130. in the "web of trust" as many old signatures are invalidated.  Please check
  131. your key rings (pgp -kc) and re-issue any signatures that have been
  132. invalidated.  PGP by default offers to remove such signatures.  Even if you
  133. leave them in, they are not trusted.
  134.  
  135. Another RSAREF limitation is that it cannot cope with keys longer than
  136. 1024 bits.  PGP now prints a reasonably polite error message in such a
  137. case.
  138.  
  139. OTHER CHANGES:
  140.  
  141. The support files are thinner.  The various contrib directory utilities
  142. have not been updated since 2.3a, and since the PGP developers know how
  143. annoying it is to have people using an ancient version and complaining
  144. about a bug in a program that was fixed a year ago, they have been
  145. omitted rather than annoy the contributors in this way.  Also, the
  146. language translation file, language.txt, is incomplete.  The strings
  147. that were in 2.3a are there, and some that could be updated without
  148. much knowledge of the language, but others that are new to 2.5 are
  149. untranslated.  The format should be obvious and some tools for
  150. manipulating the language traslations are included in the contrib
  151. directory.
  152.  
  153. Printed KeyIDs have been incresed to 32 bits, as there were enough keys
  154. out there that 24-bit keyIDs were no longer sufficiently unique.  The
  155. previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID.
  156. For example, what was printed as A966DD now appears as C7A966DD.
  157.  
  158. The config-file options
  159.     pubring=<filename>,
  160.     secring=<filename>, and
  161.     randseed=<filename>
  162. have been added.  Hopefully, the uses will be obvious.  With these, you can
  163. keep keyrings anywhere you like.  Of course, they can also be specified on
  164. the command line with +pubring= (or abbreviated to +pub=).
  165.  
  166. If the line
  167.     comment=<string>
  168. appears in the config file, the line "Comment: <string>" appears in
  169. ASCII armor output.  Of course, you can also use this from the
  170. command line, e.g. to include a filename in the ASCII armor, do
  171. "pgp -eat +comment=filename filename recipient".
  172.  
  173. PGP now enables clearsig by default.  If you sign and ascii-armor a
  174. text file, and do not encrypt it, it is clearsigned unless you ask
  175. for this not to be done.
  176.  
  177. The now enables textmode.  Textmode detects non-text files and
  178. automatically turns itself off, so it's quite safe to leave on all
  179. the time.  If you haven't got these defaults yourself, you might
  180. want to enable them.
  181.  
  182. All prompts and progress messages are now printed to stderr, to make them
  183. easier to find and ensure they don't get confused with data on standard
  184. output such as pgp -m output.
  185.  
  186. PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random
  187. data in an attempt to force disk compressors to overwrite as much data as
  188. possible.
  189.  
  190. On Unix, if the directory /usr/local/lib/pgp exists, it is searched
  191. fror help files, language translations, and the PGP documentation.  On
  192. VMS, the equivalent is PGP$LIBRARY:.  (This is PGP_SYSTEM_DIR, defined
  193. in fileio.h, if you need to change it for your site.)
  194.  
  195. Also, it is searched for a default global config.txt.  This file may
  196. be overridden by a local config.txt, and it may not set pubring,
  197. secring, randseed or myname (which should be strictly personal)
  198.  
  199. The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as
  200. fr.hlp.  Now, there is a separate help file for pgp -k, called pgpkey.hlp,
  201. or <language>key.hlp.  No file is provided by default; PGP will use
  202. its one-page internal help by default, but you can create such a file
  203. at your site.
  204.  
  205. On Unix systems, $PGPPATH defaults to $HOME/.pgp.
  206.  
  207. PGP used to get confused if you had a keyring containing signatures from
  208. you, but not your public key.  (PGP can't use the signatures in this case.
  209. Only signatures from keys in the keyring are counted.)
  210. PGP still can't use the signatures, but prints better warning messages.
  211. Also, adding a key on your secret key ring to your public keyring
  212. now asks if the key should be considered ultimately-trusted.
  213. Prviously, you had to run pgp -ke to force this check, which was
  214. non-obvious.
  215.  
  216. Due to a few people distributing PGP without the manual (including one
  217. run of a few thousand CD-ROMs), and the resultant flood of phone calls
  218. from confused users, PGP now looks to make sure a manual is somewhere in
  219. the vicinity when running to discourage this sort of thing.  (If you're
  220. getting this warning and need details on how to get rid of it, try pgp -kg.)
  221.  
  222. On Unix, PGP now figures out the resolution of the system clock at run
  223. time for the purpose of computing the amount of entropy in keystroke
  224. timings.  This means that on many Unix machines, less typing should be
  225. required to generate keys.  (SunOS and Linux especially.)
  226.  
  227. The small prime table used in generating keys has been enlarged, which
  228. should speed up key generation somewhat.
  229.  
  230. There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!)
  231. when generating primes 2 bits over a multiple of the unit size (16 bits
  232. on PC's, 32 bits on most larger computers), if the processor doesn't deal
  233. with expressions like "1<<32" by producing a result of 1.  In practice,
  234. that corresponds to a key size of 64*x+4 bits.
  235.  
  236. Code changes:
  237.  
  238. At the request of Windows programmers, the PSTR() macro used to translate
  239. string has been renamed to LANG().
  240.  
  241. The random-number code has been *thoroughly* cleaned up.  So has the
  242. IDEA code and the MD5 code.  The MD5 code was developed from scratch and
  243. is available for public use.
  244.  
  245. The Turbo C makefile was dropped in favour of a Borland C .prj file.
  246. You can use makefile.msc as a guide if you need one for a command-line
  247. Turbo C.
  248.  
  249. Changes to PGP 2.4:
  250.  
  251. - Fixed a bug with the -z <passphrase> option.  If no passphrase was given,
  252.   PGP used to crash.
  253.  
  254. - When using -c, the IV is generated properly now, and the randseed.bin
  255.   postwash is done.  (This bug could have resulted in the same ciphertext
  256.   being generated for the same plaintext, if the same passphrase is used.)
  257.  
  258. - Memory allocated with halloc() is now freed with hfree() in ztrees.c and
  259.   zdeflate.c.  (MS-DOS only.)
  260.  
  261. - The decompression code now detects end of input reliably, fixing a
  262.   bug that used to have it produce infinite amounts of output on come
  263.   corrputed input.  Decompression has also been sped up.
  264.  
  265. - PGP -m won't try to write its final output to the current directory.
  266.   This makes it less efficent if you want to save the text to a file, but
  267.   more secure if you don't.
  268.  
  269. - Number of bits allowed when generating keys limited to 1024, in line
  270.   with the limits in RSAREF and BSAFE.  It used to be higher, but
  271.   folks, if you think you need a key larger than that, do some research
  272.   into the complexity of factoring.
  273.  
  274. - Version number changed to pgp2.4
  275.  
  276. News for PGP 2.3a
  277.  
  278. There was a bug in PGP's handling of clear-signed messages when lines
  279. were terminated with CR-LF pairs.  This has been revamped.  The previous
  280. limit on the length of lines in clear-signed messages has been eliminated.
  281.  
  282. The randseed.bin file was not closed when read, which resulted in it
  283. not being rewritten with a new value under some operating systems.
  284. Fixed.
  285.  
  286. Not all of the bytes in randseed.bin were being used, resulting in less
  287. randomness than desired when picking session keys.  While it did not make
  288. the compromise of session keys likely, it was undesirable and has been fixed.
  289.  
  290. PGP should now compile with less difficulty under OS/2.
  291. The Turbo C makefile was incorrect.  Fixed.
  292. The VMS build files were out of date.  Fixed.
  293.  
  294. PGP was not accepting octal escapes in the language.txt file that did not
  295. begin with \0.  \377 is now acceptable.
  296. The language.txt file got mangled in the middle somehow.  Fixed.
  297.  
  298. News for PGP 2.3
  299.  
  300. This PGP 2.3 release has several bug fixes over PGP 2.2, and a few
  301. new (although somewhat esoteric) features.  Among them are:
  302.  
  303. - An important bug: there was a bug with compression under MS-DOS which
  304.   caused the wrong piece of memory to be freed, with results that ranged
  305.   from none to undecodable messages to machine crashes.
  306.  
  307. - When adding keys, PGP now properly closes all the files it opens, so
  308.   you don't run out of file handles (MS-DOS) or file descriptors (UNIX).
  309.  
  310. - Sometimes PGP would not properly ask the user to set trust parameters
  311.   when keys were validated by adding new signatures.  This has been
  312.   fixed.
  313.  
  314. - When PGP messages are sent through a MIME mail system, a conflict
  315.   arises over the use of the '=' character.  PGP can now decode ASCII
  316.   armored messages which have been mangled by MIME's quoting mechanism.
  317.  
  318. - PGP previously kept track of one pass phrase (from the PGPPASS
  319.   environment variable, the file descriptor named by the PGPPASSFD
  320.   environment variable, a -z <password> option, or previous user
  321.   prompts), and tried it if it needed a subsequent pass phrase.  This
  322.   caused bugs if you attempted something that required two pass phrases,
  323.   such as pgp -sc (sign and conventionally encrypt).  PGP now keeps
  324.   track of any number of pass phrases, including multiple -z options,
  325.   and uses them as necessary.  Mostly, it just Does The Right Thing,
  326.   but if you care, the exact algorithm is as follows:
  327.  
  328.   - There is a pool of private-key pass phrases that starts out with the
  329.     contents of the PGPPASS environment variable (if any), and has every
  330.     pass phrase that is successfully used to unlock a private key added
  331.     to it.  When a private key needs unlocking, every pass phrase in the
  332.     pool is tried first.
  333.   - There is a list of PGP pass phrases available for use by whatever needs
  334.     one.  This is initialized with the -z command-line options and the
  335.     phrase read from the PGPPASSFD file descriptor.  When a pass phrase
  336.     is needed, it is taken from the front of that list.  When a pass
  337.     phrase is needed to unlock a secret key, every key on the list is tried,
  338.     and if it "fits" and unlocks the secret key, it is moved to the key
  339.     pass phrase pool.
  340.   - If the above fails to produce a pass phrase, the user is prompted to
  341.     supply one.
  342.  
  343.   Key generation (we need all the keystrokes we can get for random-number
  344.   accumulation) and key signing (to make sure the user really means to do
  345.   what they're doing) are exceptions; the user is always prompted for a
  346.   pass phrase under those circumstances.
  347.  
  348. New options:
  349.  
  350. +pkcs_compat=n
  351.     This defaults to 1, which tells PGP to generate encryption key
  352.     and signature blocks in a format derived from the PKCS standards.
  353.     This format is understood (but not generated) by PGP 2.2.  If set
  354.     to 0, the old format is generated, which may be needed for
  355.     portability to PGP versions before 2.2.  PGP is still incompatible
  356.     with the PKCS standards in many ways, but in future, values of 2
  357.     or higher may be used to produce formats which are more compatible.
  358.  
  359. Other notes:
  360.  
  361. The MS-DOS executable was compiled with Borland C++ version 3.0, optimized
  362. for maximum speed, except that jump optimisation was turned off.  If it
  363. is turned on, the Transform() function in md5.c is compiled incorrectly.
  364. The pgp.prj file that was used is included in the source distribution.
  365.  
  366. Thanks to everyone who worked on PGP and sent in bug reports.  Two who
  367. didn't make it into the manual are to Lindsay DuBois for a bit of last-
  368. minute translation, and Reptilian Research for support in developing PGP.
  369.  
  370. And thanks to the Cypherpunks who managed to get PGP so much attention
  371. in Wired magazine recently.
  372.  
  373. I hope you enjoy PGP!
  374.  
  375.     -Colin <colin@nyx.cs.du.edu>
  376.  
  377. News for PGP 2.2
  378.  
  379. The main change since PGP 2.1 is a speedup in key management, and 
  380. the ability to encrypt for more than one recipient.  Apart from
  381. this there are some bugfixes and some new options to make it easier
  382. to use PGP from shell scripts or mailers.
  383.  
  384. You can encrypt for more than one recipient by specifying additional
  385. userids on the command line eg:
  386.  
  387.     pgp -e plaintext Alice Bob Carol
  388.  
  389.  
  390. Some notes about the changes:
  391.  
  392. - PGP doesn't do a keycheck on a keyfile before it is added anymore,
  393. this is to speed up merging a big keyfile with your public keyring which
  394. may already have most of the keys in the keyfile you are adding.  After
  395. PGP has checked a signature it sets a flag in your public keyring to
  396. mark this signature as checked.  Because PGP 2.1 didn't have these
  397. flags, PGP will check *all* signatures on your keyring the first time
  398. you add a key with PGP 2.2.  After that PGP will only check new
  399. signatures.  Also by using an older version than 2.2 on your keyring you
  400. will clear these flags again.
  401.  
  402.  
  403. New options:
  404.  
  405. +interactive
  406.     If you add a keyfile, PGP will ask for each new key if it should
  407.     be added to your keyring.
  408.  
  409. Options for use in shell scripts:
  410.  
  411. +verbose=n
  412.     The default is 1.  With +verbose=0, PGP will only print an error
  413.     message if something goes wrong.  With +verbose=2, PGP will tell
  414.     you what it's doing in detail suitable for debugging.
  415.  
  416. +force
  417.     Overwrite output file without asking, or with -kr: remove key
  418.     without asking (only if it has just one userid).
  419.  
  420. +batchmode
  421.     With this option PGP won't ask any questions or prompt for
  422.     alternate file names.  Some of the key commands still need
  423.     user interaction and can't be done from a shell script.
  424.     You can also use this option to check if a file has a good
  425.     signature.  If the input file did not have a signature the exit
  426.     code will be 1, if the file had a signature and if it checked OK
  427.     the exit code will be 0.  Note that if the input file has more
  428.     than one armored messages, a good signature on one of these
  429.     messages will make the exit code 0 (if there are no errors).
  430.  
  431. These "long" options can be abbreviated as long as the abbreviation is
  432. unambiguous.  "interactive" and "verbose" can also be set in config.txt;
  433. you can then turn these flags off on the command line with +option=.
  434.  
  435.  
  436. Some of the bug fixes:
  437.  
  438. - Key lookup on keyID (eg 0x12AB) fixed for -ks/-krs.
  439.  
  440. - Dearmoring of Macintosh type text files (CR only) now also works.
  441.